[00:00.970 --> 00:06.730]  Good afternoon, everybody. My name is Nimit. I'm one of the co-founders at Votes.
[00:07.050 --> 00:14.010]  And I'm here to talk about some of the security data we've collected during the course of our
[00:14.010 --> 00:20.010]  mobile voting pilots over the last couple of years. So before we dive into the data,
[00:20.010 --> 00:27.990]  just a quick overview about Votes. As many of you may know, Votes is the youngest elections company
[00:27.990 --> 00:36.910]  in the US. We got started almost by accident after winning a hackathon at South by Southwest
[00:36.910 --> 00:43.390]  in Austin, Texas, way back in 2014. The theme of the hackathon was Hack to the Future.
[00:43.410 --> 00:49.050]  What's the one thing you would do in the future and how you do it? And so my brother and I,
[00:49.050 --> 00:56.710]  he was there and we ended up prototyping this new election system, which used smartphones,
[00:56.710 --> 01:04.590]  biometrics, real-time identity verification, and then also locked the ballots on a blockchain-based
[01:04.590 --> 01:10.290]  infrastructure. To our surprise, we ended up winning the first prize and that led to a whole
[01:10.290 --> 01:19.130]  series of events and eventually the company started in 2015. So since then, we've done 67
[01:19.130 --> 01:28.310]  elections so far and 11 of these have been public government election pilots. We've also done
[01:28.310 --> 01:34.490]  non-governmental elections, primarily with the state political parties in various states.
[01:34.490 --> 01:42.150]  And so some of the data we're going to share today covers a wide array of our elections
[01:42.150 --> 01:47.970]  from a security perspective. And then we'll also dive in into a couple of really interesting
[01:47.970 --> 01:54.110]  elections we did recently, where for the first time we were able to collect a lot of interesting
[01:54.110 --> 02:04.210]  data. So I'll begin with a quick introduction about our system. It's a smartphone app-based
[02:04.210 --> 02:12.410]  mobile voting platform and the key components here are essentially the voters' smartphone devices,
[02:12.410 --> 02:17.330]  an iPhone or a compatible Android. Then you have the cloud infrastructure
[02:18.330 --> 02:24.670]  where the backend servers are running and also distributed blockchain infrastructure.
[02:24.870 --> 02:31.450]  And then you have the election administration-specific interfaces to the election
[02:31.450 --> 02:37.610]  jurisdiction. And then from there, their traditional infrastructure is ballot printers
[02:37.610 --> 02:46.130]  and tabulation equipment. And the way the entire process works is essentially, right now,
[02:46.130 --> 02:52.950]  the system is being piloted only for absentee voters. And within absentee voters, a very small
[02:52.950 --> 02:59.930]  subset of people, essentially military voters who are deployed, their families and any U.S.
[03:00.790 --> 03:09.230]  overseas, they're commonly referred to as Yokawa voters. And so if you're in that eligible group
[03:09.230 --> 03:15.930]  and your jurisdiction is participating in a pilot, then you sign up normally as an absentee voter
[03:15.930 --> 03:22.990]  and then submit a form to your election clerk, typically your county clerk, and then they do
[03:23.130 --> 03:27.770]  a little bit of vetting. And then if you're eligible, they will pre-provision you on the
[03:27.770 --> 03:34.570]  system. And then you get an invitation to download the application on your smartphone, iPhone or
[03:34.570 --> 03:40.970]  compatible Android device. So you begin with the email number and email ID and a mobile number.
[03:40.990 --> 03:48.610]  And then once you've done the initial onboarding, you are asked to do an identity check. So you'll
[03:48.610 --> 03:54.610]  have to take a picture of a government-issued photo ID. Right now, you can use a driver's
[03:54.610 --> 04:01.730]  license, state ID or passport. You can use some other forms of ID as well if you don't have
[04:01.730 --> 04:07.390]  those three, but those are the most commonly used ones. And then once you've done the scan
[04:07.390 --> 04:13.310]  in the application front and back, then you're asked to take a live video selfie.
[04:13.870 --> 04:19.890]  Then once you've completed that, it does a matching to make sure the picture you took of yourself
[04:19.890 --> 04:28.390]  matches the picture on the ID. Liveness check is done as well to weed out any fakes or
[04:28.390 --> 04:35.730]  any other kind of fraudulent activity. And once everything matches, the data on your ID is compared
[04:35.730 --> 04:42.530]  to the voter registration file which is provided to us by the jurisdiction for the pilot. All that
[04:42.530 --> 04:50.790]  matches, your identity is digitized, stored in the secure space on the handset, and all the
[04:50.790 --> 04:56.150]  documents you've provided are deleted at that point because we don't need them. We don't want
[04:56.150 --> 05:01.710]  to increase the threat surface after that as well. So at this point, you're ready to receive your
[05:01.710 --> 05:09.990]  ballot. So as you can see from the flow diagram, that's essentially a 10-step process. And once
[05:09.990 --> 05:14.890]  you've received the ballot, it's essentially your mobile representation of your actual paper ballot
[05:14.890 --> 05:21.490]  which you would receive if you went to work in person at your precinct, or if you opted into
[05:21.490 --> 05:28.230]  vote by mail, essentially the same ballot you'd get here. And so you map the ballot on the phone,
[05:28.230 --> 05:33.490]  and then you may be asked to sign an affidavit. Sign with the finger on the screen, and then
[05:33.490 --> 05:38.630]  once you're ready to submit, you confirm your choices, do your biometric verification on the
[05:38.630 --> 05:45.250]  device again, and at that point your ballot gets submitted to the network, anonymized, and you get
[05:45.390 --> 05:54.010]  a receipt so you can verify your selections, and then also participate in the audit process as well.
[05:54.250 --> 06:00.490]  And in the background, the jurisdiction gets an anonymized and anonymized copy of your receipt,
[06:00.490 --> 06:06.450]  and then close to election day, a paper ballot is printed. And then there's a pre-tabulation audit
[06:07.170 --> 06:13.230]  on election day. Printed paper ballots are tabulated just like other paper ballots,
[06:13.950 --> 06:19.870]  and there's no hand reproduction required. And then once the election's over, during the canvas
[06:19.870 --> 06:26.070]  phase, there's a full audit where receipts are prepared. So end-to-end, that's how the process
[06:26.070 --> 06:34.510]  works. Now that we've looked at kind of how the system functions, let's look at the threat model.
[06:34.510 --> 06:42.310]  So as you can see, it's a pretty interesting threat model here, obviously, because it's an
[06:42.310 --> 06:49.530]  internet-connected device. It is different from traditional methods of voting. So let's kind of
[06:49.530 --> 06:57.070]  run through the flow, and at each step we can look at some of the threats. This is the first
[06:57.070 --> 07:03.890]  phase, as you saw, you opted in, the county clerk approves you, and then you've started to download
[07:03.890 --> 07:10.570]  the app. So obviously, if you're not careful, you could download an incorrect app by mistake, or
[07:11.150 --> 07:17.550]  the app may already be compromised ahead of time by a bad actor, or there may be malware on your
[07:17.550 --> 07:22.570]  device which, you know, prevents normal functioning of the application. So it's kind of the first
[07:22.570 --> 07:28.670]  stage. Next, look at, now you're at the voting stage, so the threats here are maybe the biometric
[07:28.670 --> 07:35.110]  capability on your phone isn't working as it's supposed to. And obviously, at this stage,
[07:35.110 --> 07:40.630]  if there's malware, your apps can be reverse engineered, and there can be attempts made to
[07:41.470 --> 07:47.910]  change how you're voting. So that's the threat vector, and we'll see how there are ways to mitigate
[07:47.910 --> 07:54.870]  that a little bit later. Then obviously, in the transmission phase, the transmission is not secure,
[07:54.870 --> 08:00.790]  the transmission channel, that data may never reach the destination or may corrupt it on the
[08:00.790 --> 08:06.670]  way. So we look at ways as to how that can potentially be mitigated as well. And then
[08:06.670 --> 08:14.250]  the voter gets a receipt. So the receipt, there's a chance somebody else may get hold of your receipt
[08:14.250 --> 08:19.790]  if you're not careful. Obviously, that's an active area of research on how to create
[08:19.790 --> 08:28.570]  self-destructing receipts, but it's a potential threat vector. And so finally, once the ballots
[08:28.570 --> 08:33.840]  reach the jurisdiction, as they are printing the paper ballot for tabulation,
[08:34.350 --> 08:41.650]  and they do a pre-tabulation audit, so there is a potential threat vector which would likely get
[08:41.650 --> 08:47.030]  caught by the pre-tabulation audit. Nevertheless, important to keep in mind.
[08:47.030 --> 08:53.210]  Thank LA Times for making this nice picture available to us. Very nicely done. Makes it
[08:53.210 --> 08:59.430]  simple to understand. And so now that we've looked at the high-level threat model,
[08:59.430 --> 09:05.370]  let's look at what kind of threats we've seen in the wild over the last couple of years.
[09:05.610 --> 09:11.630]  So we like to group them into a few different categories. So there's obviously threats at the
[09:11.630 --> 09:18.630]  device level. There's threats at the network level. And so those are kind of user-centric
[09:18.630 --> 09:25.410]  scenarios. And then overall is the cloud infrastructure, our corporate network. So
[09:25.410 --> 09:32.870]  obviously those are areas of interest as well. So in terms of what we've seen, passive scanning,
[09:32.870 --> 09:39.950]  obviously, which happens to pretty much everybody these days who has a public-facing web asset.
[09:39.950 --> 09:46.950]  We've also seen active analysis of our web assets. So people actually trying to
[09:46.950 --> 09:54.110]  reverse engineer some of that stuff. And phishing of our staff, clients.
[09:55.230 --> 10:01.750]  Email spoofing attempts as well. Social engineering, obviously we're well aware of
[10:01.750 --> 10:09.930]  what happened recently. We've had attempts, phone calls, people pretending to be who they're not.
[10:09.950 --> 10:16.790]  We've seen DNS tampering attempts as well. SIM swap, SIM takeover attempts. And then
[10:16.790 --> 10:24.230]  reverse engineering of the mobile applications, sometimes partial. And then through the analysis,
[10:24.230 --> 10:30.630]  mobile API level attacks. So people actually trying to figure out how the API is working
[10:30.630 --> 10:37.910]  and trying to attack it. We've also seen on the Android side attempts to compromise the TEE,
[10:37.910 --> 10:47.150]  some of the TEEs are stored. And then malware, we do come across malware on several devices. And
[10:47.830 --> 10:54.230]  we'll see later on in one of our lectures, an interesting case that came to light.
[10:55.110 --> 11:01.130]  So before we dive into some of the data, it's going to be useful to look at the MITRE attack
[11:01.130 --> 11:07.530]  framework. So recently, MITRE updated the mapping for not just the enterprise side,
[11:07.530 --> 11:14.750]  which covers the cloud aspects in our case, but also the mobile side. So we mapped that data to
[11:14.750 --> 11:22.150]  what we've seen, as you can see on iOS, some interesting things to note and the device level.
[11:22.690 --> 11:30.210]  And then similarly, network-based vectors. So we already spoke about the SIM swap. And then
[11:30.210 --> 11:37.510]  you'll see some of the other ones in the data head, such as rogue Wi-Fi and things like that.
[11:38.290 --> 11:45.350]  Similarly, on the Android side, similar to iOS, a couple of different things,
[11:45.350 --> 11:52.890]  but we find the mapping useful, just as we plan out our work. And I'm sure a lot of you are
[11:52.890 --> 11:58.850]  looking at this as well. Similarly, on the network side for Android,
[11:59.790 --> 12:08.570]  let's look at a few case studies here. 2018 was when we had first opportunity to do public
[12:08.570 --> 12:17.430]  elections in the US. And so since then, we've had some interesting opportunities to collect data.
[12:17.650 --> 12:25.110]  So we'll start with something from 2018. One of the really interesting things we saw early on
[12:25.110 --> 12:33.210]  back then was the attempts to use multiple devices with the same adversary and using
[12:33.910 --> 12:40.710]  different mobile numbers and emails and trying to do the same thing. So in that scenario,
[12:40.710 --> 12:48.170]  the mitigation deployed by the system was to treat this as a malicious activity and block
[12:48.170 --> 12:55.790]  office access. We did see people use phone numbers in some telco blacklist,
[12:56.490 --> 13:03.490]  as well as people using well-known tools like WebSuite to probe the platform, probe the API
[13:03.490 --> 13:09.990]  endpoints. And in one of these cases, we were able to record the traffic through a honeypot.
[13:09.990 --> 13:16.310]  So some of that is available as part of the open data package and is also available. We'll share
[13:16.310 --> 13:21.670]  some public links at the end of the presentation, so you can get it from there as well.
[13:22.310 --> 13:29.050]  The other interesting thing from a case study perspective was people trying to reverse
[13:29.050 --> 13:36.910]  engineer the application. The system has an initial handshake process and we saw some attempts,
[13:36.910 --> 13:42.970]  manual attempts to engineer that handshake process. And so in that scenario as well,
[13:42.970 --> 13:49.190]  one of the mitigations was to block the IP address ranges or block the device IDs,
[13:49.190 --> 13:55.630]  depending on the nature of the attack. But that's an area where we have some feedback on
[13:56.310 --> 14:05.210]  better approaches to mitigate those kinds of attempts. Email spoofing, so we did see,
[14:05.210 --> 14:11.070]  we continue to see a lot of email spoofing attempts and obviously with DMARC that helps
[14:11.070 --> 14:19.090]  to mitigate that, but nevertheless we do keep track of it. Another interesting case study was
[14:19.090 --> 14:28.370]  involved, essentially network-based attempts to scan the passively and then use that information
[14:28.370 --> 14:35.110]  to actively look at infrastructure, particularly the API endpoints. So that's where we see a lot
[14:35.110 --> 14:43.650]  of interest. And then more recently we've had an opportunity to do somewhat larger elections
[14:43.650 --> 14:49.690]  in terms of participation. Some of the early pilots had a very small number of voters, so
[14:49.690 --> 14:55.750]  the opportunity to collect meaningful data was a little limited from a security,
[14:55.750 --> 15:05.090]  on-device security, network security perspective. But with one of the elections this year,
[15:05.090 --> 15:13.250]  some very interesting data to analyze, and so I'd love to share that. One focuses around,
[15:13.250 --> 15:19.310]  we call it the mobile threat detection. We partner with third parties for that capability as well as
[15:19.310 --> 15:26.710]  some stuff we have. And the way that's structured is, we call it a multi-channel
[15:26.710 --> 15:33.170]  component architecture. The device is communicating with obviously our back-end,
[15:33.170 --> 15:39.090]  it's also communicating with the third-party system. Similarly, our back-end is communicating
[15:39.090 --> 15:46.470]  with the third-party system. A good example was, somebody tries to reverse-engineer the app
[15:47.330 --> 15:53.650]  and hooks the specific locations where some of that code is getting triggered to try and bypass
[15:53.650 --> 16:00.230]  it. You could potentially disrupt two of these channels, but it'd be hard to disrupt the third
[16:00.230 --> 16:08.710]  channel. So that, in this case, acts as a saving grace and also as a extra detection mechanism.
[16:09.410 --> 16:16.830]  And so some of this capability is actively deployed. Next, probably the most interesting
[16:16.830 --> 16:23.550]  part of the presentation. So this is data from one of our recent elections, where a few thousand
[16:23.550 --> 16:32.290]  people participated. And this was kind of the device split, predominantly more iOS than Android.
[16:32.290 --> 16:39.990]  And then in terms of the threats we detected, on the network side, it was pretty even, 50-50.
[16:40.210 --> 16:47.370]  But on the device side, we saw sort of a lopsided share of threats being detected on Android.
[16:47.370 --> 16:50.810]  That could be a function of the devices that were being used,
[16:51.450 --> 16:58.910]  or maybe the unique factors to this election as well. But something interesting to keep in mind.
[16:59.310 --> 17:05.050]  Sort of diving one level deeper. So on the iOS side, let's kind of look at some of the network
[17:05.650 --> 17:11.230]  security threats. And this data, by the way, is available in the open data set.
[17:11.250 --> 17:17.350]  I believe it's the part one. So you can kind of dive in at your convenience as well.
[17:17.370 --> 17:27.570]  But at the iOS level, we saw 18 devices who were connected. So this was amongst the few thousand
[17:27.570 --> 17:35.490]  and the 64% who were using iOS. There were 18 devices detected which the Wi-Fi was deemed to be
[17:35.490 --> 17:42.910]  unsafe. And so obviously that creates a potential for a man-in-the-middle type of attack. So the
[17:42.910 --> 17:49.630]  experience was they were not able to complete the process on the device or ask to contact
[17:49.630 --> 17:56.410]  the support team. In that case, they were requested to either switch to the cellular network
[17:56.410 --> 18:04.350]  or switch to a different Wi-Fi network. In this case, once they did that, they were able to proceed.
[18:06.170 --> 18:14.110]  Similarly, on Android, similar number, about 17. On Android, we also saw an interesting case
[18:14.110 --> 18:23.170]  for potential ARP poisoning. ARP is address resolution protocols, I'm sure many of you know.
[18:23.170 --> 18:28.790]  In this case, it was a little hard for a support team to detect because we didn't have visibility
[18:28.790 --> 18:35.630]  into what the voter's home network looked like. And so it required a little bit of troubleshooting,
[18:35.630 --> 18:42.710]  but eventually turned out to be a media device which was causing this poisoning. And so the team
[18:42.710 --> 18:48.970]  requested the voter to turn off the media device. And then the threat went away and they were able
[18:48.970 --> 18:55.970]  to proceed. So an area we'd love to do a little more research, but it was interesting that we
[18:55.970 --> 19:05.110]  came across this one case. Next, let's look at some device level threats. On the iOS side, we did
[19:05.110 --> 19:10.570]  detect a few devices where the pin was not set. In that case, mitigation and resolution was to force
[19:10.570 --> 19:17.410]  the users to send in or activate the biometrics on the device. Otherwise, they couldn't really proceed.
[19:17.930 --> 19:26.390]  And we saw a few cases of side-loaded apps. And in each of those cases, when a little bit of
[19:26.390 --> 19:31.970]  due diligence was done, they were deemed to be legitimate apps. And so the voters were able to
[19:31.970 --> 19:38.670]  proceed. It was good to see them being detected in case they could pose a threat.
[19:38.670 --> 19:45.030]  So definitely something we'd like to research more on. On the Android side, a much larger number
[19:45.030 --> 19:51.890]  of devices without pins, which we weren't sure why, but was interesting. 89 devices didn't have
[19:51.890 --> 19:58.190]  pins set, so all those voters were forced to set a pin or activate the biometric capability on the
[19:58.190 --> 20:06.110]  devices. Similarly, on the side-loaded side of things, a lot more side-loaded apps, which kind
[20:06.110 --> 20:14.250]  of made sense given the ecosystem on Android. So it did take quite a bit of time to go through these,
[20:14.250 --> 20:20.030]  make sure everything was okay. Luckily, the election went for three days, so our support team
[20:20.030 --> 20:26.730]  had enough time to troubleshoot. In this investigation, we did find two instances where
[20:26.730 --> 20:32.990]  the device did have malware. And it was a fairly well-known malware. I'm sure many of you probably
[20:32.990 --> 20:40.390]  heard about it. But it was interesting that we were able to detect this, inform the voter,
[20:40.390 --> 20:47.390]  they were able to delete the offending apps, reset the devices, and then proceed. And then
[20:47.390 --> 20:52.730]  once the new checks were confirmed, they were actually able to vote successfully and complete
[20:52.730 --> 20:59.010]  the audit as well. A couple of other interesting Android-specific things, we did detect some
[20:59.010 --> 21:06.070]  instances of USB debugging being enabled. Nothing malicious on that front, but during
[21:06.070 --> 21:12.830]  the active voting, the phone was not connected to a computer. So that was fine. And then we did
[21:12.830 --> 21:21.170]  have another 21 devices where developer options were enabled. So once again, no direct impact,
[21:21.170 --> 21:28.470]  but something we'd like to keep track of. And as I mentioned earlier, this data is available as part
[21:28.470 --> 21:38.130]  of the package we've released. We'd love more feedback and suggestions on how to collect,
[21:38.130 --> 21:43.750]  how to analyze this in a better way, especially areas around malware and
[21:44.710 --> 21:50.490]  other really interesting things we were able to learn from here.
[21:51.330 --> 21:57.350]  And you'll notice that the data is, for the most part, anonymized. And that's true of the
[21:57.350 --> 22:05.130]  collection process as well. The voter is the one who's asked to initiate and not knowing what
[22:05.130 --> 22:13.430]  exactly has happened. So the data does not contain any personally identifying information, to the
[22:13.430 --> 22:21.170]  best of our knowledge. And lastly, love any suggestions and feedback from the community.
[22:21.170 --> 22:28.530]  We're a young company, the youngest company in this space, trying to do something which is
[22:28.530 --> 22:34.670]  unusual, to say the least. And so we'd love suggestions and feedback to improve and what
[22:34.670 --> 22:41.470]  things we could do better. And appreciate the participation of the community. Thank you for
[22:41.470 --> 22:50.490]  the DEF CON voting village team for giving us this opportunity to share this data. And we'll be
[22:50.490 --> 22:59.450]  sharing more of this data as we do more election pilots. And we'd love to continue to get feedback
[22:59.450 --> 23:06.790]  from everybody. More information is available on our website, especially under white papers and
[23:06.790 --> 23:13.670]  under the security section. So please feel free to explore and give us feedback and look at the
[23:13.670 --> 23:20.630]  data as it's posted in the future as well. Once again, thank you and hope you all have a
[23:20.630 --> 23:26.690]  great DEF CON experience this year, especially at the voting village. Thank you. Take care.
